fix: Enable union type support in @opentelemetry/instrumentation-graphql (#1506) #2923
Conversation
nitrofski
changed the title
nitrofski
changed the title
|
Hi @nitrofski and thanks for your contribution. I order to proceed we need a couple of things:
Cheers |
|
@obecny can you please take a look at this? |
|
I merged with main. There are issues with CLA approval at my company at the moment, which we are working on getting resolved. I will sign as soon as that's done. Sorry for the delay. |
|
CLA issues have been resolved. |
|
@obecny can you please take a look at this? |
|
Good day, This hasn't seen feedback in over a month. Is there anything I can do to help get attention on this PR? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2923 +/- ##
==========================================
- Coverage 92.66% 92.66% -0.01%
==========================================
Files 237 237
Lines 11232 11230 -2
Branches 2329 2327 -2
==========================================
- Hits 10408 10406 -2
Misses 824 824
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
| ): void { | ||
| if ( | ||
| !type || | ||
| typeof type.getFields !== 'function' || |
There was a problem hiding this comment.
I'm not familiar enough with this library. Are we certain that all possible values of type have a function named getFields?
There was a problem hiding this comment.
It is part of graphqlTypes.GraphQLObjectType. As long as we maintain type safety and that the type definitions are accurate (to my testing, they were), we should be safe.
The previous implementation used an any type before recursing, so they lost type safety and ended up passing non-compliant object. It had to re-assess the object here.
|
|
||
| // unwrap union types | ||
| if (isGraphQLUnionType(type)) { | ||
| return type.getTypes(); |
There was a problem hiding this comment.
Here I have a similar question. Are we certain that getTypes() returns an array of GraphQLObjectType. Could be possible to have nested unions?
There was a problem hiding this comment.
Fair concern. Doing a quick search through the graphql type definitions, GraphQLUnionType is the only type with a getTypes() function, and it always returns an array of GraphQLObjectType. That all being said, is it enough for us or do we want to be extra safe and also validate what the function returns at runtime?
There was a problem hiding this comment.
Could be possible to have nested unions?
Doing a bit of research...
From the Apollo Graphql Union and Interfaces schema help page
All of a union's included types must be object types (not scalars, input types, etc.). Included types do not need to share any fields.
It sounds like unions strictly require their components to be objects and that nested union are not allowed. Though, to dispel any doubts, I tried launching my graphql server with a dummy union type that uses other union types:
Union type MyTestUnion can only include Object types, it cannot include <other union type>.
There was a problem hiding this comment.
thanks for your thorough explanation @nitrofski :)
|
@nitrofski thank for resolving my doubts. You have my approval but I'll wait a bit in case someone else wants to do a review. @obecny maybe? |
|
@nitrofski I'm merging this today so it will be included in the upcoming release Could I ping you if there is any issue in this new version? Thanks :) |
|
Thank you for your contribution @nitrofski! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. |
Sure, I can help. FYI I have another PR on the same package coming. |
4 participants
Which problem is this PR solving?
Fixes #1506.
Short description of the changes
Enable support for installing field instrumentation on union types.
The "type unwrap" logic was generalized to support unwrapping to a list of types. It is now a recursive function rather than a loop. The new unwrapping has been implemented in a way that is more agreeable to TypeScript.